# Получение задач
## Описание
Процесс, в результате которого у команды появляются задачи, над которыми она работает.

На чем делают фокус:

- Люди, которые ставят задачи команде
- Люди, ставящие задачи конечным исполнителям
- Необходимые условия для получения задачи в команду
- Процесс внутренней подготовки задачи к реализации

## Почему ветка важна?
Прозрачный для заказчиков и исполнителей процесс позволяет эффективно выполнять именно те задачи, которые решают проблему. Хорошо выстроенный процесс позволяет:

Тимлиду:
- Прогнозировать загрузку и сроки выполнения прилетающих задач
- Предоставить понятный интерфейс получения задач для заказчиков
- Уменьшить простой исполнителей

Исполнителям:
- Фокусироваться непосредственно на решении задач

## Что будет, если её не делать?
Непроработанный процесс получения задач приводит к:

- Дополнительным раундам уточнения цели задачи
- Исполнители неправильно понимают проблему заказчика. Результат не решает проблему
- У исполнителей появляется больше одного постановщика задач. Необходимо приоритезировать задачи не только внутри бэклога, но и между ними
- Начало реализации откладывается, так как не выполнены все предусловия

## На кого может быть делегирована?
На проектного менеджера, линейного тимлида


## Примеры поведения
### Примеры плохого поведения
- Конечный исполнитель переключается между несколькими бэклогами.
- Заказчик общается напрямую с разработчиками, продавливает сроки.
- Исполнители простаивают, потому что задачи в бэклоги не готовы.
- Заказчики не понимают когда будет сделана та, или иная задача.
- Появляются значительные переработки из-за многократного уточнения условий задачи.
- Излишний формализм в постановке задачи не позволяет понять цель её выполнения.

### Примеры хорошего поведения
- Роли чётко определены, всем участникам понятен процесс постановки задач в команду.
- Исполнители понимают не только что надо сделать, но и зачем.
- Простои и переработки минимальны.

## Способы прокачки
### Практика
Следующий алгоритм поможет настроить процесс получения задач в команду

1. Необходимо понимать кто является заказчиками и стейкхолдерами задач, выполняемых командой. Необходимо прояснить ожидания от команды, а также её ответственности
2. Надо сформулировать интерфейс взаимодействия заказчика с командой. Обеим сторонам должно быть понятно в каком виде прилетают требования заказчика. В некоторых случаях это общее описание проблемы с пользовательскими кейсами, сформированные при помощи лида или системного аналитика. В других – согласованное ТЗ с макетами. Аналогично происходит со сроками: или они гибкие и оценка команды согласуется с заказчиком, или дедлайны опускаются сверху.
3. Формируется процесс изменения требований заказчиком. Возможны ли правки? Если возможны, то на каком этапе?

Эти пункты важны для выбора методологии разработки. Обычно она выбирается исходя из необходимости действовать гибко.

Проблемы, с которыми можно столкнуться, и возможные решения:

- Заказчик опускает скоуп и сроки
  - Можно пожертвовать расширяемостью решения. Но надо понимать, что это локальная оптимизация времени, которая приведёт к большим срокам на дистанции
- Во время приёмки задачи становится ясно, что решение не закрывает проблему заказчика
  - Потеря знания о проблеме происходит на одном из этапов: формулирования проблемы заказчиком или превращения требований в задачи исполнителей. Обычно ретроспективно удаётся локализовать потерю этих знаний


### Консультации
- [Чат TeamLead Bootcamp](https://t.me/tlbootcamp)
